COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.SEC(Projects)
C00009 00003	.SS(Pretty-printing,,P226:)
C00010 00004	.SS(Data Bases,,P222:)
C00011 00005	.SS(Syntax-directed processes,syntax-directed)
C00012 00006	.SS(Syntax directed computation,syntax-directed,P4:)
C00013 00007	.SS(One-pass assemblers)
C00021 ENDMK
C⊗;
.SEC(Projects)
This chapter consists of a set of non-trivial projects which either apply LISP 
or extend LISP by adding new language features.
.SS(Extensions to %3eval%*,%3eval%*,P67:)
.SELECT 1;


.BEGIN TURN ON "#";
This next extension to %3eval%*  was derived from the syntax of 
⊗→MUDDLE↔←⊗↑[Mud#75]↑, ⊗→CONNIVER↔←⊗↑[Con#73]↑, and
⊗→MICRO-PLANNER↔←⊗↑[Mic#71]↑.
We have seen that LISP calling sequences are of two varieties: either
evaluate %2all%* of the arguments; or  evaluate %2none%* of the
arguments.

In an attempt to generalize this regime we might allow the evaluation of some
of the arguments and enlarge on the domain
of objects which can appear in the list of λ-variables.
We might partition the formal parameters into required parameters, optional 
parameters, and an excess collector to handle any actual parameters left over.
Required parameters %2must%* have corresponding actual parameters; optional
actual parameters are used if present, otherwise declared default 
values are used.
If there are more actual parameters than the formals encompassed by the first
two classes, then they are associated with the excess collector.

To be more precise consider the following possible BNF equations:

.BEGIN TABIT1(13);TURN OFF "←";

<varlist>\::=[<required> <optional> <excess>]

<required>\::= <par>; ...;<par> | %cε%* ⊗↓The symbol "%cε%1" stands for the empty string.←

<optional>\::= "optional" <opn>; ...; <opn> | %cε%*

<excess>\::= "excess" <par> | %cε%*

<par>\::= <variable> | %9`%*<variable>

<opn>\::= <par> | <par> ← <form>

.END
.GROUP;
The associated semantics are as follows:

.BEGIN INDENT 0,10;TURN OFF "←";
%21.%*  The formal parameters are to be bound to the actual parameters from
left to right  as usual.

%22.%*  There must be an actual parameter for each required parameter, and
if there is no excess collector there may not be more actual parameters than
formals. (There may be fewer if we have optionals.)

%23.%*  If a <variable> in a formal parameter is preceded by a "%9`%*", then
the corresponding actual parameter is %2not%* evaluated. This is just the
%3quote%1-ing %3read%1 macro.

%24.%*  We might run out of actual parameters while binding the optionals.
If we do, then we look at the remaining formal optionals.
If a formal parameter is simply a <par> then we bind it to %3(#)%*; if a formal is
%9`%1<variable> ← <form> then we bind the <variable> to the <form>; 
and if the formal is
<variable> ← <form>, we bind <variable> to the value of <form>, where the
evaluation is to take place %2after%1 the required parameters have been bound.

%25.%*  Finally, the excess collector is bound to a list of any remaining
actual parameters in the obvious way: if <par> is <variable> then 
using the calling environment, form a list
of the values of the remaining arguments; 
if it is %9`%1<variable>, bind <variable> to the
actual list. If there is no excess, bind to %3NIL%*.
.END
.APART

.BEGIN TURN OFF "←";
We will also extend %3prog%*-variables slightly, allowing 
them to be initialized explicitly. If a %3prog%*-variable is atomic,
intialize it to %3(#)%*, as usual. If it is of the form <variable>#←#<form>
then initialize it to the value of the <form>.
.END
.END

.BEGIN TURN OFF "←";turn on "\"; tabs 10,18;
Here are some examples:

1. In the initialization of %3length%* on {yon(P45)}, we could write:
%3...#prog[[l#←#x;#c#←#0]#....%*

2. %3list%* could now be defined as: %3λ[[%1"excess"%* x]x]%*.

3. Consider the following definition:
.BEGIN NOFILL;
.group

\%3baz <= λ[\[x;%9`%*y;%1"optional"%* z; u ← 0; %1"excess"%* v]
\\print[x];
\\print[y];
\\print[z];
\\print[u];
\\print[v] ].
.APART
.GROUP
%1Then a call of:

.BEGIN CENTER;
%3eval[(BAZ 2 (CAR (QUOTE (X Y))) 4 5 6 7 (CAR (QUOTE (A . B))));NIL]%* 
.END

would print:%3 \\2  
\\(CAR(QUOTE (X Y)))
\\4
\\5 
\\(6 7 A)%*

and return value: %3(6 7 A)%*.
.APART

.GROUP
Similarly, defining:

\%3fii <= λ[\[x;y;%1"optional"%* z; u ← 0; %1"excess"%3 v]
\\print[x];
\\print[y];
\\print[z];
\\print[u];
\\print[v]].

.BEGIN CENTERit;
%1and calling: ←%3eval[(FII 2 (CAR (QUOTE (X Y)));NIL]%* 
.END
prints:%3\\2 
\\X 
\\NIL 
\\0 
\\NIL.%*
.END
.END

.CENT(Problems);

Design simple S-expr representations of these proposed constructs.
Make these extensions to %3eval%*.
.SS(Pretty-printing,,P226:)

also read macros and meta brackets
.SS(Data Bases,,P222:);
.SS(Syntax-directed processes,syntax-directed)
%1
.REQUIRE "NOTES.SDP" SOURCE_FILE;
.SS(Syntax directed computation,syntax-directed,P4:)

compilation for sae

BNF for mexprs

syntax directed compiler

scanner parser

general syntax directed computation
.SS(One-pass assemblers)
.P10:


Write a one-pass assembler for the code generated by the %3compile%* function
of this section. You should be aware of the following points:

.BEGIN INDENT 0,5;

%2a.%*  %3QUOTE%*d expressions must be protected from garbage collection. The
simplest way to accomplish this it to  save them on a list, say %3QLIST%*.

%2b.%*  Use the operation codes of {yonss(P7)})

%2c.%*  Design a simple fixup scheme.  Notice that %3compile%*'s code will
require address fixups at most.

%2d.%*  Recall that the format of the code is a list. The items in the list are
either atomic -- representing labels --, or lists -- representing instructions--.
The instructions have varying format.  Perhaps a ⊗→table-driven↔← scheme can be used.

%2e.%*  Some attempt should be made to generate error messages.

%2f.%*  Many of the constants, %3(C n)%*, occur frequently; these constants
are only referenced, never changed by execution of the compiled code.  Write
your assembler to maintain only one copy of each. The constants should be stored
directly after the compiled code.  

%2f%*.  Try to be equally clever about storing %3QUOTE%*d expressions.
.END